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I.  General 


Weinberg7 1 


CR23, 001 


Van  Nostrand  (1971)  pp.  1-288. 

Naur69b 

Naur,  P. ,  and  Randell,  B.  (ed. ) ;  Softwar 
NATO  Scientific  Affairs  Division,  Bru 
(1969)  pp. 1-231. 

Buxton7 1 

Buxton,  J.N.;  The  Nature  and  Implications 

Engineering;  The _ Fourth _ Generation^  I 

Berkshire,  England  (1971)  pp. 227-238. 


In  this  paper,  Bi 
software  engineering 
computer  science,  and  then  by  explaining 
engineering  differs  from  it. 


is,  by  first 


Fosdick72 

Fosdick,  L.D.;  The  Production  of  Better 
Software;  Communications  of  the  ACM,  vol. 
1972)  pp. 611-617. 
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the  org 
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validation,  docu 
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mechanics  of  the 
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16*19 

r  programming; 

9*18 

e  En 

gineering ; 

ssel 

s,  Belgium 

3*15 

of 

Software 

nfotech.  Ltd., 

ke  c 

lear  what 

ying 

to  define 

how 

sof  tware 

,  he 

discusses 

ing. 

1*15 

Ma 

thema  tical 

15, 

no. 7  (July 

ons 

are  made 

re  production, 
s  the  problem 
are,  it  is  not 
ties  of  this 
e  divided  into 
mentation  and 
upling  between 
questions  of 
production  of 
Baker. 


The  article  is  uneven  and  perhaps  too  shallow  in 
its  treatment  of  the  problems  in  the  areas  discussed, 
but  it  is  provocative.  It  suggests  in  simple  terms  the 
areas  that  every  programmer  must  consider  if  he  is  to 
be  able  to  be  at  all  successful  in  producing  worthwhile 
programs.  It  provides  a  first  crack  at  a  reading  list 
for  programmers  in  support  of  their  professional 
responsibilities.  One  very  interesting  idea  emerges 
from  the  article  and  that  is  the  idea  of  truly 
automatic  program  documentation,  the  latter  to  be 
interpreted  in  a  broad  sense. 
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Bauer  7 1 


Bauer,  F.L.;  Software  Engineering;  Proceedings  of  IFIP 
Congress  1971,  Booklet  I  (August  1971)  pp. 267-274. 

Buxton70 

Buxton,  J.N.,  and  Randall,  B.  (ed.);  Software 
Engineering  Techniques;  NATO  Scientific  Affairs 
Division,  Brussels,  Belgium  (1970)  pp. 1-164. 

R iddle7  2 


Riddle,  W.E.;  An  Annotated  Bibliography  on  Software 
Architecture;  Stanford  Linear  Accelerator  Center, 
Computation  Group,  no.  138  (September  1972)  pp. 1-103. 

Turski70 


Turski,  W. 
Programs ; 


(ed.)  ; 
Polish 


The  Efficient  Production  of  Large 
Academy  of  Sciences  (1970)  pp. 1-130. 
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II  .__M  a  nage  men  t 


Baker72  CR23,113  11*16 

Baker,  F.T.;  Chief  Programmer  Team  Management  of 
Production  Programming;  IBM  Systems  Journal,  vol.  11, 
no.  1  (1972)  pp. 56-73. 


Bake 
operation 
particula 
inf ormat i 
represent 
prograiami 
individua 
a  consta 
together 


r  describes,  in  detail,  the  organization 
of  a  chief  programmer  team  involved 
r  task:  the  programming  of  the  N.Y. 
on  bank  system.  The  chief  programmer 
s  an  integration  of  previously 
ng  management  techniques  that  have 
lly  tried  in  the  past.  If  they  are  appli 
nt  manner  over  an  entire  project,  they 
well . 
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Times 
team 
known 
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work 


Mills7 1  a 


8*16 


Mills,  H. ; 
Procedures ; 
(June  1971) 


Chief  Programmer  Teams:  Principles  and 
IBM  Federal  Systems  Division,  no. FSC7 1-5 1 08 


Wolfe69 


1*15 


Wolfe,  J.M.;  Testing 
Datamation,  vol. 15,  no. 4 


for  Programming 
(April  1 969)  . 


Aptitude ; 


Schwartz70 


5*14 


Schwartz,  J.D.;  Analyzing 
Development;  in  Buxton,  J.N., 
Software  Engineering  Techniques 


137. 


Large-scale 
and  Randall, 
(April  1970) 


System 

B.  (ed . )  , 

pp. 122- 


Very  large  programs  are  define 
require  "many  times  the  available  pr 
code  and  data  and  require  "more  than 
implementation.  The  implementation  o 
an  expensive,  difficult  undertaking  a 
many  of  them  has  demonstrated  that  th 
a  complete  understanding  of  the  metho 
necessary  to  accomplish  successfully 
systems. 
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author  has  been 

involved  in 

checkout 

of 

a  number 

of  large- 

systems. 

He 

first  describes  some 

large-sca 

le 

systems,  then  outline 

problems 

associated  with 
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problem. 
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ds  and  technology 
the  aims  of  these 
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scale  programming 
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s  in  detail  the 
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McMonigall70  2*13 

McMonigall,  J.P.;  Criteria  for  the  Design  and 
Implementation  of  Application  Packages  for  Third  - 
Generation  Computers;  Software  70  (1970)  pp. 92-97. 

McMonigall  is  associated  with  a  software  house 
that  provides  application  packages  to  its  own  service 
bureau  as  well  as  to  customers.  From  his  experience  in 
applications  package  design,  he  breaks  the  process  into 
seven  phases;  pre-design,  market  research,  initial  cost 
estimation,  design  and  evaluation  of  the  technical 
system,  post-design,  implementation,  and  systems 
review.  The  article  gives  an  overall  view  of 
applications  package  design  and  advocates  starting  from 
scratch  design  as  opposed  to  *• packageising"  an  existing 
system. 

Bemer69  9*12 

Berner,  R.W.;  Checklist  for  Planning  Software  System 
Production;  in  Naur,  P. ,  and  Randell,  B.  (ed.).  Software 
Engineering  (1969)  pp. 165-180. 

The  implementation  and  production  of  software 
systems  is  an  expensive,  difficult  undertaking.  Good 
planning  will  reduce  cost  and  time.  Here  the  author 
provides  a  checklist  which  may  be  used  for  planning 
purposes.  The  checklist  includes  the  topics:  tooling, 
training  and  organization,  design,  scheduling  and 
costing,  production  control,  documentation,  quality 
assurance,  installation,  distribution  and  updating, 
field  reporting  and  maintenance. 

Cosgrove71  2*10 

Cosgrove,  J. ;  Needed  Now;  New  Planning  Framework; 
Datamation,  vol.17,  no. 12  (Dec.  1971). 

The  author  describes  the  problems  of  programming 
management.  Ha  discusses  what  is  wrong  with  the 
traditional  way  of  handling  programmers,  and  how  they 
should  be  dealt  with  in  this  time  of  increasingly  more 
complex  problems. 

Tsichritzis72b  3*9 

Tsichritzis,  D.;  Project  Management;  Advanced  Course  in 
Software  Engineering,  Technical  University  of  Munich, 
Germany  (February  21  -  March  4  1972). 
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Barnett70 


2*9 


Barnett,  A. ;  Training  Management  for  Effective  Data 
System  Development;  IFIP  World  Conference  on  Computer 
Education  (197  0) . 

This  paper  concentrates  on  the  activity  that  takes 
place  before  a  system  is  programmed.  The  premise  is 
that  management  must  be  trained  in  systems  development 
as  only  thus  can  data  systems  be  developed  to  perform 
the  required  functions  and  meet  realistic  and 
satisfactory  constraints. 

A  ron7  0 

Aron,  J.D.;  Estimating  Resources  tor  Large  Programming 
Systems;  in  Buxton,  J.N.,  and  Randell,  B.  (ed.). 
Software  Engineering  Techniques  (1970)  pp. 68-79. 

Berner  7  0  CR2  1,123 

Berner, R.W.;  Manageable  Software  Engineering;  in  Tou, 

J.T.  (ed.).  Software Engineering^  vol.  1  (1970) 

pp. 121-137. 

Gotterer  69  CR17,793 

Gotterer,  M.H.;  Management  of  Computer  Programmers; 
Proceedings  of  the  SJCC,  vol.  34  (1969)  pp. 419-42 4. 


Katzenelson7 1 


CR22 , 55 1 


Katzenelson,  J. ;  Documentation  and  the  Management  of  a 
Software  Project  -  A  Case  Study;  Software  -  Practice 
and  Experience;  vi 
157. 


4  K 


Kay69 
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( April- J 
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pp. 147- 
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and  debugging 
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for 
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ject) 
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be 

diff 

icult  to 

o  a 

large 

applica 

tion. 

CHI 

7,794 

Kay,  R.H.;  The  Management  and  Organization 
Software  Development  Projects;  Proceedings  of 
vol. 34  ( 1 969) pp. 425-4 33 . 


of  Large 
the  SJCC, 


This  paper  discusses  common  management  problems, 
presenting  solutions  to  some  major  problems  and 
specifying  unresolved  areas.  Some  important  key  words 
are:  real  world,  human  aspects,  system  specifications, 
documentation,  project  plan,  evaluation. 
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Liebowitz67 


CHI  2, 170 


Liebowitz,  B.H.;  The  Technical  Specification  -  Key  to 
Management  Control  of  Computer  Programming;  Proceedings 
of  the  SJCC,  vol.  30  (1967)  pp. 51-59. 

Masters68 

Masters,  P.R.;  Evaluating  Programmer  Performance;  The 
Australian  Computer  Journal,  vol.1,  no. 3  (November 
1968)  . 


This  paper  disc 
the  cost  of  writi 
example,  that  progra 
to  program  size) 
measuring  the  perfor 
control  the  cost  and 
produce.  These  me 
program  reliability 
program  (both  calend 
efficiency,  and  ea 
procedure  is  sugge 
management  knows  the 


usses  the  factors  that  influence 
ng  programs  (it  is  suggested,  for 
mining  time  is  linearly  proportional 
and  proposes  several  means  of 
raance  of  programmers  in  order  to 
effectiveness  of  the  programs  they 
asures  include  factors  such  as 
,  how  long  it  took  to  write  the 
ar  time  and  man  hours) ,  running 
se  of  modification.  A  reporting 
stad  so  that,  at  all  times, 
status  of  different  programs. 


Meush69 


Meush,  M . ; 
Datamation , 


Controlling 
vol  .15,  no.  1 1 


the 
(Nov . 


Programming  Project; 
1969) . 


Scharf 68 


Scharf,  T.;  Management  and  the  New  Software; 
Datamation,  vol.  14, no. 4  (April  1968). 

This  article  discusses  the  decisions  a  software 
manager  should  make  to  minimize  the  cost  of  design  and 
future  use  of  a  system. 

Trapnell69  CR17,822 

Trapnell,  F.M.;  A  Systematic  Approach  to  the 
Development  of  System  Programs;  Proceedings  of  the 
SJCC,  vol.  34  (1969)  pp. 411-418. 

Wrigh t68  CK1 6, 1 1 4 


Wright,  A.H.;  The  Management  of  Applications 
Programming;  Proceedings  of  IFIP  Congress  1968  (August 
1968)  pp. 414-419. 


TOPICS 


Other  management  papers: 

Corbato72,  Mealy70,  Selig69,  Steel65,  Tsichri tzis7 2a ; 
Cost  estimation: 

Aron70,  Bemer69,  Masters68,  McMonigall70,  Scarf68; 
Project  scheduling: 

Bemer69,  Garwick61,  McMonigall70 ,  Mealy70; 

Personnel : 

Barnett70,  Bemer69,  Cosgrove71,  Judd70,  Kay6 
Hasters68,  Schwartz70,  Wolfe69; 

Organization  of  personnel: 

Baker72,  Beraer69,  Brophy70,  Conway68,  Kills71a; 

Chief  programmer  teams: 

Baker72,  Mills71a; 
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III . Design 

Parnas71b  3*17 


Parnas,  D.L.  ;  Information  Distribution  Aspects  of 
Design  Methodology;  Proceedings  of  IFIP  Congress  1971, 
Booklet  TA-3  (1971)  pp. 26-30. 

The  thesis  of  this  paper  is  that  a  designer  may 
retain  tighter  control  on  the  structure  of  his  system 
if  he  controls  the  distribution  of  information.  Parnas 
observes  that  "a  good  programmer  makes  use  of  the 
useable  information  given  him”.  The  consequence  is 
that  a  good  programmer,  given  all  the  information  about 
the  system  design  will  always  find  some  efficiencies  in 
"bit  twiddling”.  The  unfortunate  side  effect  is  that 
modules  become  highly  interconnected,  making  for  nasty 
problems  later  in  the  design.  Restriction  of 
information  distribution  reduces  this  interdependency. 
Information  about  design  decisions  can  now  be  used,  by 
the  designer,  to  verify  that  the  code  produced  is 
consistent  with  design  objectives.  Several  good 
examples  are  given  which  support  the  theme  of  the 
paper. 

Ulrich70  10*16 

Ulrich,  W. ;  Design  of  High  Reliability  Continuous 
Operation  Systems;  in  Buxton,  J.N.,  and  Randell,  B. 
(ed) ,  Software  Engineering  Techniques  (1970)  pp.149- 
153. 


Cox7 1 


1*16 


Cox,  P.R. ;  Machine  -  Independent  Operating  Systems:  A 
Functional  Approach  To  Design;  in  Hugo,  J.S.  (ed.).  The 
Fourth  Generation,  (1971)  pp. 239-258. 


The  term  operating  system,  as  currently  use 
the  computer  industry,  is  virtually  undefinable. 
is  a  large  set  of  functions  that  nearly  all  oper 
systems  do  perform,  but  this  set  is  inclined  to  b 
a  little  fuzzy  around  the  edges. 
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In  this  paper,  Cox  attempts  to 
objectives  that  are  required  in  a  machine 
operating  system  and  portable  software  a 
level.  He  feels  that  more  thought  is 
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particular  machine  or  a  particular  ope 
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rating  system 
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Bar ton70 


CR21,445 


6*15 


Barton,  R .  S.  ; 
A  Personal 

pp. 7- 16. 


Ideas  for  Computer  Systems  Organization: 
Survey;  in  Tou,  J.T.(ed),  Software 
vol.1.  Academic  Press,  New  York  (1970) 


Barton  presents 
preferences  for  a  la 
In  the  paper  he  suppor 
length  paging,  variabl 
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Mealy69 


CR1 9, 621 


2*15 


Mealy,  G.H.;  The  System  Design  Cycle;  Proceedings  ACM 
Second  Symposium  on  Operating  Systems  Principles  (Oct. 
1969)  pp.1-7. 

The  steps  in  a  design  of  a  project  are  discussed 
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information,  and  ignorance 
that  systems  resemble  the 
them. 
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design,  inadequate  market 
of  Conway's  Law  which  states 
organizations  which  produced 


S teel67  CR13,919  1*15 

Steel,  T.B.;  Standards  for  Computers  and  Information 
Processing;  in  Alt,  F. L. ,  and  Rubinoff,  M.  (ed.), 
Advances_in_ComputersJL  vol.  8  (1967)  pp.  103-152. 

With  such  diversity  in  the  field  of  computer 
science,  some  form  of  unification  must  be  taken. 
Standardization  of  the  terminology,  problem  definition, 
programming  languages,  communication  characteristics 
and  physical  (i.e.,  nonelectrical)  characteristics  of 
computers  and  information  processing  devices,  equipment 
and  systems  is  a  must. 
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Weissman7 1 
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Weissman,  L. ;  Software  Interfaces  for  Computer  Systems; 
M.S.  Thesis,  University  of  Toronto,  Department  of 
Computer  Science  (1971)  pp.1-71. 
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organized  on  hierarchical  levels  which  serve  to 
implement  independent  abstractions.  Program 
correctness  and  verification  are  briefly  discussed  and 
a  short  appendix  gives  some  explanation  of  semaphores 
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and  some  results  on  prevention  of  deadlock, 


Di jkstra69 


8*14 


Dijkstra,  E.W.;  Complexity  Controlled  by  Hierarchical 
Ordering  of  Function  and  Variability;  in  Naur,  P. ,  and 
Randell,  B.  (ed.),  Software  Engineering  (1969)  pp.181- 
185. 


The  principle  of  operating  system  design  as  an 
ordered  seguence  of  machines,  each  succeeding  one  more 
attractive  (to  the  user)  is  presented.  Each  machine  is 
implemented  by  an  additional  layer  of  software  over  the 
basic  machine.  A  description  and  justification  for  the 
particular  layers  used  in  the  T.H.E.  System  is 
given. 
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Parnas72b 
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Parnas,  D.L.;  A  Technique  for  Software 
Specifications  with  Examples;  Communications 
ACM,  vol.  15,  no.  5  (May  1972)  pp.  330-336. 
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Parnas,  D.L.;  A  Paradigm  for  Software  Module 
Specification  with  Examples;  Car negie-Mellon 
University,  Department  of  Computer  Science  (March  1971) 
pp. 1-  19. 

Cohen72  2*14 

Cohen,  A.;  Modular  Programs:  Defining  the  Module; 
Datamation,  vol. 18,  no.  1  (Jan.  1972)  pp.  34-37. 

Modular  programming  is  a  useful  tool  if  applied 
skillfully.  The  author  gives  a  feeling  for  the  right 
decomposition  of  your  problem  into  modules  by 
considering  typical  file  processing  programs. 
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Strachey7  1b 


2*14 


Strachey,  C. ;  The  Interaction  of  Software  Engineering 
and  Machine  Structure;  The_Fourth_Genera tion^  Infotech, 
Ltd,,  Berkshire,  England  (1971)  pp. 341-356. 


Randell69 


Randell,  B.T.;  Towards  a  Methodology  of 
System  Design;  in  Naur,  P. ,  and  Randell, 
Software  Engineering  (1969)  pp. 204-208. 
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Dennis,  J.B.;  Segmentation  and  the 
Multiprogrammed  Computer  Systems;  Journal 
vol.12,  no. 4  (October  1965)  pp. 589-602. 
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Tsichritzis,  D. ;  Lecture  Notes  on  Operating  Systems; 
University  of  Toronto,  Department  of  Computer  Science, 
Technical  Report  no.44(August  1972)  pp. 1-290. 

This  readable  set  of  notes  gives  a  great  deal  of 
background  and  information  to  both  the  technical  and 
managerial  aspects  of  software  engineering.  It  also 
contains  an  annotated  bibliography. 
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(1969)  pp.  138-155. 


2*10 

Produced  Software  Components;  in 
11,  B.  (ed.).  Software  Engineering 


Brinch  Hansen70 
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Brinch  Hansen,  P. ;  The  Nucleus 
System;  Communications  of  the 
1970)  pp. 238-241 ,250. 
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Balzer7 la 


CR22, 799 
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Balzer, 

R  .  K .  ; 

Communic 

a  tion 

vol.38  ( 

1971) 

As 

an 

should 

be 

PORTS  -  A  Method  for  Dynamic  Inter program 
and  Job  Control;  Proceedings  of  the  SJCC, 
pp. 485-489. 


extension  of  Dataless  Programming,  one 
allowed  to  freely  interchange  physical 
devices,  terminals,  files,  other  programs,  and  a 
monitor  as  the  object  of  a  specific  communication.  By 
using  PORTS  and  a  set  of  commands  such  as  CONNECT, 
DISCONNECT,  SEND,  RECEIVE,  CONDITIONAL  RECEIVE, 

REQUEST,  and  CONDITIONAL  REQUEST,  modules  may  be 
reconnected  in  alternate  configurations  or  "monitor 
modules”  may  be  incorporated  between  the  input  and 
output  of  two  or  more  components  of  the  system.  Balzer 
explai  ns  his  ideas  in  terms  of  his  Incremental  Systems 
Programming  Language  which  uses  an  extension  of 

Dijkstra*s  semaphores. 


Judd70 
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Judd,  R. ;  Practical  Modular  Programming; 
Bulletin,  vol.14,  no. 1  (1970)  pp.4-7. 


Computer 


The  obvious  merit  of  modular  programming  is  that 
it  enables  programming  to  be  divided  among  several 
programmers  working  concurrently,  and  allows  better 
testing  and  validation  by  groups  who  may  not  be  aware 
of  the  detailed  methods  used  in  a  particular  module. 
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control  should  be  handled  by  one  module  and  if  module- 
to-raodule  calls  are  required,  these  should  be  executed 
through  a  'dispatching  module'  which  operates  the 
linking  mechanism. 


Cor bato72 


5*9 


Corbato,  F.J.,  Saltzer,  J.H.,  and  Clingen,  C.T.; 
MULTICS  -  The  First  Seven  Years;  Proceedings  of  the 
SJCC,  vol. 40(1972)  pp. 571-583. 

Although  intended  as  a  review  and  current  status 
report,  this  paper  provides  an  interesting  description 
of  the  progress  of  the  design  and  implementation  of  a 
very  large,  very  complex,  research  project  with  real 
life  goals.  In  their  conclusions,  the  authors  make  the 
point  that  computer  utility  systems  must  evolve,  since 
the  costs  of  redesign  and  re-implementation  are  too 
high  to  allow  any  other  procedure.  This  is  almost 
certainly  true  of  any  very  large,  complex  system  which 
is  to  serve  a  community  of  users  who  (1)  will  not  wait 
for  the  ultimate  to  arrive  at  the  expense  of  not  doing 
anything  until  it  does;  (2)  are  used  to  a  particular 
environment,  and  see  no  real  need  to  unlearn 
everything . 

Steel  65  CK8,551  2*9 


Steel,  T.B.;  The  Development  of  Very  Large  Programs; 
Proceedings  of  IFIP  Congress  1965,  vol.1  (1965)  pp.231- 
235. 


Parnas 


69a 
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Parnas,  D.L.;  On  the  Use  of  Transition  Diagrams  in  the 
Design  of  a  User  Interface  for  an  Interactive  Computer 
System;  Proceedings  of  the  24th  ACM  National  Conference 
(1969)  pp. 379-385. 
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particular,  he  proposes 
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modification. 

Halstead72  3*7 

Halstead,  M.H.;  Natural  Laws  Controlling  Algorithm 
Structure?;  SIGPLAN  Notices,  vol.7,  no. 2  (February 
1972)  pp. 22-30. 

The  author  proposes  that  algorithms  obey  natural 
laws,  which  are  based  on  two  independent  properties, 
the  number  of  distinct  operators  and  the  number  of 
distinct  operands.  A  certain  function  of  these 
properties,  called  the  Internal  Quality  of  an 
algorithm,  is  said  to  be  independent  of  the  language  in 
which  the  given  algorithm  is  expressed.  Though  the 
results  are  inconclusive,  the  potential  implications  in 
programming  design  should  warrant  further  research. 

A lexa  nder64 

Alexander,  C .  ;  Notes_on_the_Sy_nthesis_of _For mg  Harvard 
University  Press,  Cambridge  (1964). 

Balzer7  1  b 

Balzer,  R.M.  ;  On  the  Future  of  Computer  Program 
Specification  and  Organization;  Rand  Corporation,  Santa 
Monica,  Cal.,  no.  R-622-ARPA  (August  1971). 

Belady 7  1 

Belady,  L.A.,  and  Lehman,  M.M.;  Programming  System 
Dynamics  or  the  Meta-Dynamics  of  Systems  in  Maintenance 
and  Growth;  IBM  Research  Center,  Yorktown  Heights, 
N.Y.,  no.  RC  3546  (September  1971). 

Constantine65 

Constantine,  L. ;  Towards  a  Theory  of  Program  Design; 
Data  Processing  Magazine,  vol.7,  no.  12  (December  1965) 

pp.  18-21. 

Constantine66  CR13,619 

Constantine,  L.L.  (ed. ) ;  Concepts_in _ Program _ Designg 

Paragon  Press,  Somerville,  Mass.  (1966)  pp. 1-154. 

Conway63b 

Conway,  M.E.;  A  Multi-processor  System  Design; 
Proceedings  of  the  FJCC,  vol.  24  (1963)  pp. 139-146. 


16 


Conway68 
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Daniels,  A.E.;  Some 
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D i jkstra7  la 

Dijkstra,  E.W.;  Hierarchical  Ordering  of  Sequential 
Processes;  Acta  I nf or matica ,  vol.  1,  no.  2  (1971) 
pp. 115-138. 


Gauthier70 


CR20, 829 


Gauthier,  R.L.,  and  Ponto, 
Programs Prentice- Hall ,  Inc. 


S.D.;  Designing _ Systems 

(1970)  pp.  1-274. 


A  textbook,  complete  with  problem  sections, 
designed  to  give  an  overall  view  of  the  problem  of 
implementing  a  large  software  project,  and  to  provide  a 
reference  collection  of  programming  techniques.  The 

development  of  these  ideas  is _ based  on  the  modular 

design  and  logical  structure  of  a  compiler  system. 

G  ha  n7 1  CR22,433 


Ghan,  L. ;  Better  Techniques  for  Developing  Large  Scale 
FORTRAN  Programs;  Proceedings  of  the  26th  ACM  National 
Conference  (1971)  pp. 520-537. 
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Cost  reductions,  particularly  in  the  develo 
of  large  scale  FORTRAN  scientific  computer  prog 
are  desirable,  but  are  not  easy  to  realize  becaus 
enduring  development  problems  associated  with 
programs.  This  paper  examines  the  more  significan 
these  problems  and  suggests  ways  to  treat  them, 
problems  addressed  here  were  identified  over  a  p 
of  years  spent  developing  a  family  of  large  FO 
simulation  programs  at  Boeing.  The  techn 
discussed  were  evolved  during  the  development  of 
programs  and  are  of  proven  effectiveness.  Parti 
emphasis  is  placed  on  the  use  of  higher  level  soft 
interprogram  communication  techniques  and  good 
coding  practices. 

Gill6  9 

Gill,  S.  ;  Thoughts  on  the  Sequence  of  Writing  Soft 
in  Naur,  P.,  and  Randell,  B.  (ed.),  Sof 
Engineering  (1969)  pp. 186-188. 

Hartman67  CR14,049 

Hartman,  P.H.,  and  Owens,  D.  H.  ;  How  to  Write  Sof 
Specifications;  Proceedings  of  the  FJCO,  vol.31  ( 
pp. 779-790. 

Hicks68 


Hicks,  H.T.;  Modular  Programming  in  Cobol;  Datama 
vol.14,  no. 5  (May  1968). 
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Hoare,  C.A.R.;  Proceedings  of  the  International  Se 
on  Operating  Systems  Techniques;  Queen's  Universi 
Belfast  (1971). 


Hopkins70 


Hopkins,  B.E.;  Computer  Aided  Software 
Buxton,  J.N.,  and  Randell,  B.  (ed 
Engineering  Techniques  (1970)  pp. 99-101. 
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Huxtable67  CR14,976 

Huxtable,  D.H.R.,  and  Warwick,  M.T.;  Dynamic 
Supervisors-Their  Design  and  Construction;  Proceedings 
of  ACM  Symposium  on  Operating  System  Principles 
(October  1967) . 

This  is  one  of  the  first  papers  to  emphasize  a 
"layered”  approach  to  operating  system  design  and 
construction.  It  describes  the  design  of  a  structured, 
process- oriented ,  easily  modified  system.  It  is 
suggested  that  the  invariant  ’•kernel"  be  micro¬ 
programmed,  substituting  hardware  for  software. 

Jackson7 1 

Jackson,  W.C.;  General  Principles  of  Software  Design; 
University  of  Alberta  Computing  Review,  vol.4  (May 
1971)  pp.  39-50. 

A  short  article  which  explores  some  of  the  general 
principles  of  software  design.  It  outlines  the  major 
steps  in  preparing  a  piece  of  software,  from  the  design 
stage  to  the  documentation  of  the  system,  and  suggests 
a  few  ways  in  which  to  develop  more  efficient, 
reliable,  and  understandable  software. 

Johnson68 

Johnson,  C.I.;  Principles  of  Interactive  Systems;  IBM 
Systems  Journal,  vol.7,  no. 3  and  4  (1968)  pp. 147-173. 

MacGowan64 

MacGowan,  R.A.;  Modular  Programming;  Data  Processing 
Magazine,  vol.6,  no. 10  (October  1964)  pp. 49-53. 

Madnick70 

Madnick,  S.E. ;  Design  Strategies  for  File  Systems; 
M.I.T.,  Project  MAC,  no.TK-78  (October  1970)  pp. 1-106. 

This  report  exemplifies  the  idea  of  "top-down"  or 
"levels  of  abstraction"  analysis  as  applied  to  the 
design  of  file  systems.  The  two  basic  concepts  imposed 
on  the  analysis  are  that  files  should  (except  for  the 
top-most  user  oriented  level)  be  subject  to  a  uniform 
representation,  and  that  the  tasks  of  naming,  storing 
and  retrieving  information  should  be  analyzed  into  a 
hierarchy  of  activities  ranginy  from  the  purely  logical 
to  the  purely  physical. 

A  file  is  viewed  as  a  named,  sequentially 
organized  (virtual)  memory.  That  is,  the  items  of 
information  in  the  file  are  considered  to  be  assigned 
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to  sequential  "addresses”.  The  fact  that 
(say)  related  by  a  tree  structure  is  of 
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these  modules  are  discussed. 
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Dijkstra,  E.W.;  Notes  on  Structured  Programming; 
Technological  University,  Department  of  Mathematics, 
no.  70-WSK-03,  Eindhoven  (1970). 
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Dijkstra,  E.W.;  The  Humble  Programmer;  Communications 
of  the  ACM,  vol.15,  no. 1 0  (October  1972)  pp. 859-866. 

The  author  reflects  on  the  historical  development 
of  programming.  Initial  hardware  constraints  and  the 
nature  of  the  slowly  developing  field  resulted  in 
puzzle- minded  programmers  that  optimized  the  computing 
process.  The  introduction  of  second  and  third 
generation  computers  only  heightened  the  problems. 


In  looking  to  the  future  he  fore 
that  are  of  limited  size  now  will 
less  effort  and  many  fewer  bugs, 
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given,  as  well  as  some  impedimen 
programmers,  it  is  necessary  to  reali 
of  the  problems,  the  usefulness  of 
limitations  of  the  human  mind. 
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Dijkstra,  E.W.;  Structured  Programming;  in  Buxton, 
J.N.,  and  Randell,  B.  (ed.).  Software  Engineering 
Techniques  (1970)  pp. 84-87. 

A  discussion  of  the  amount  of  reasoning  required 
to  understand  an  arbitrary  program  leads  to  the 
conclusion  that  the  production  of  a  correct  program  can 
be  accomplished  most  easily  by' successive  refinement  of 
an  abstract  program. 
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Hills,  H.;  Mathematical  Foundations  of  Structured 
Programming;  IBM  Federal  Systems  Division,  no.FSC72- 
6012  (February  1972)  pp.1-62. 
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Dijkstra,  E.W.;  Programming  Considered  as  a  Human 
Activity;  Proceedings  of  IFIP  Congress  1965,  vol. 1 
(1965)  pp. 213-217. 

The  main  thrust  of  this  paper  is  that  the 
programmer  and  his  mind  are  an  important  part  of  the 
computing  process.  The  use  of  these  parts  of  the 
process  is  not  necessarily  optimized  by  making  poorer 
use  of  the  machine.  Rather  there  can  be  a  gain  in 
efficiency  of  usage  of  the  machine  by  using  top-down, 
GOTO-less  program  structuring  which  is  more  easily 
created  and  understood  by  humans. 


The  paper  suggests  that  investigation  be  done  to 
see  to  what  degree  the  goals  of  humans  and  the 
characteristics  of  the  machine  are  parallel,  and  that 
we  do  not  flatly  assume  that  these  are  opposites. 

The  author  asserts  that  elegance  leads  to 
desirable  features  of  programming  languages.  As  the 
title  implies,  he  approaches  programming  through  the 
basic  pattern  of  human  understanding.  From  this 
attitude  he  criticizes  programming  to  date  and 
descr ibes  more  natural  and  elegant  structures. 


Dijkstra  gives  a  clear  statement  of  successive 
refinement  of  a  problem,  emphasizing  (1)  division  into 
parts,  (2)  the  parts  together  form  the  whole,  and  (3) 
the  principle  of  non-interference.  Here  also  are  his 
classic  arguments  for  program  correctness  and  against 
the  HG0-T0”.  He  proposes  four  desirable  language 
features  and  concludes  that  an  area  for  work  is  that  of 
the  compromises  of  efficency  against  convenience. 
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Inc.  (1971)  pp. 41-55.” 
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n  of  functional  specifications  to  simpler  and 
unctions,  until  statements  of  the  programming 
itself  are  reached”.  Two  principles  are 
-  1)  verification  of  correctness  at  each  step 
utilization  of  only  a  few  basic  control 
s:  simple  sequencing,  IF  THEN  ELSE,  and  DO 
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WHILE. 


The  ideas  presented  can  be  used  to  create  a 
structured  program  from  design  specifications,  or  given 
a  large  system,  reorganize  it  into  a  set  of  more 
readable  segments.  The  resultant  programs  can  be  read 
sequentially  in  small  segments,  each  segment  from  top 
to  bottom,  with  all  control  paths  visible,  because  of 
GO  TO  free  code  and  library  and  macro  facilities. 
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Wulf,  W.A.;  Programming  Without  the  Goto;  Proceedings 
of  IF IP  Congress  1971,  Booklet  TA-3  (1971)  pp. 85*88. 
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Dijkstra,  E.W.;  Go  To  Statement  Considered  Harmful; 
Communications  of  the  ACM,  vol.11,  no. 3  (Mar.  1968) 

pp. 147-148. 

The  concept  of  independent  co-ordinates  with  which 
to  describe  the  progress  of  a  process  is  discussed. 
Such  co- ordinates  cannot  be  found  if  unstructured 

control  transfers  are  allowed  in  programming  languages. 
Suggestions  are  made  for  alternative  constructions  that 
are  both  flexible  and  structured  so  that  an  independent 
co-ordinate  system  can  be  maintained. 
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ease  or  difficulty  of  the  problem.  This 
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An  example  of  top-down  development  o 
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The  technique  to  provide  mobility  is  based  on  the 
concept  of  an  abstract _ machine  -  a  hypothetical 
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computer  ideal  for  a  particular  task.  The  program  for 
this  task  is  written  for  the  abstract  machine  and  to 
run  such  a  program  on  a  real  machine,  the  abstract 
machine  must  first  be  realized  in  some  way. 

The  author  concludes  the  article  by  discussing 
both  the  advantages  and  disadvantages  of  the  technique 
of  abstract  machine  modelling  and  points  out  that  the 
system  has  proved  extremely  mobile  in  practice,  having 
been  implemented  in  less  than  one  man-week  on  nine 
different  occasions. 
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Bounce-and-skip  provides  the  user  with  two 
options: 

1.  To  delay  the  use  of  the  result  of  a  test 

indefinitely 

2.  To  make  the  entry  and  exit  of  BEGIN-END  blocks 
conditional  upon  the  last  test  performed. 

Each  test  performed  is  coded  as  either  neutral 
(its  result  has  already  been  used) ,  successful  or 

unsuccessful.  This  indicator  is  matched  to  a  list  of 
permissible  settings  of  the  indicator  associated  with 
each  BEGIN  and  END.  Under  a  mismatch  condition  control 
is  prohibited  from  entering  through  a  given  BEGIN  and 
thus  it  skips  the  block,  or  control  is  not  allowed  to 

exit  through  a  given  END  and  hence  it  bounces  and 

positions  itself  just  after  the  corresponding  BEGIN. 
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Project  SUE;  SIGPLAN  Notices,  vol.6,  no. 9  (October 
1971)  pp. 79-88. 
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McCracken,  D.D.,  and  Weinberg,  G.M.;  How  to  Write 
Readable  FORTRAN  Programs;  Datamation,  vol.18,  no. 10 
(October  1972)  pp. 73-77. 

For  ease  of  documentation  and  for  readability, 
programmers  should  observe  the  described  rules 
concerning  comments,  ”goto"s,  do-loops,  complicated 
expressions,  statement  numbers  and  variable  names. 

Knuth71b  CR22,300  3*13 

Knuth,  D.E.;  An  Empirical  Study  of  FORTRAN  Programs; 
Software  -  Practice  and  Experience,  vol.  1,  no.  2 
(April/June  1971)  pp. 105-133. 

This  paper  deals  with  a  study  of  a  sample  of 
programs  written  in  FORTRAN  by  a  wide  variety  of  people 
for  a  wide  variety  of  applications.  Statistical 
results  of  the  study  are  presented  in  the  paper, 
together  with  some  of  their  apparent  implications  for 
future  work  in  compiler  design.  The  principal 
conclusion  which  may  be  drawn  is  the  importance  of  a 
table  of  frequency  counts  which  record  how  often  each 
statement  is  performed  in  a  typical  run.  With  the 
table  of  frequency  counts,  a  programmer  or  an 
optim  izing  compiler  may  optimize  a  program  by  merely 
optimizing  those  portions  of  his  program  which  are 
executed  most  frequently,  and  thus  reduce  the  amount  of 
time  spent  in  producing  efficient  programs. 

McKeeman67  CR14,136  5*12 


McKeeman,  W.M.;  Language  Directed  Computer  Design; 
Proceedings  of  the  FJCC,  vol. 31  (1967)  pp. 413-417. 
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Wulf ,  W.,  Geschke,  C.,  Wile,  D.,  and  Apperson,  J. ; 
Reflections  on  a  Systems  Programming  Language;  SIGPLAN 
Notices,  vol. 6,  no. 9  (October  1971)  pp. 42-49. 
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Bergeron,  R.D.,  Gannon,  J.D.  ,  Shecter,  D.P.,  Tompa, 
F.W.,  and  van  Dam,  A.;  Systems  Programming  Languages; 

in  Rubinoff,  M .  (ed.).  Advances in Computers^  vol. 

12,  Academic  Press,  New  York  (1972)  pp. 175-284. 
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Ashcroft,  E.,  and  Manna,  Z. ;  The  Translation  of  "go  to" 
Programs  to  "while"  Programs;  Proceedings  of  IFIP 
Congress  1971,  Booklet  TA-2  (1971)  pp. 147-152. 
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Hoare69 
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An  Axiomatic 


Hoare,  C. A. R . ; 

Programming;  Communications 
(Oct.  1969)  pp. 576-580. 


McKeeman66 


CR  1  3, 436 


4*11 

h a  s i s  for  Com  put e  r 
of  the  ACM,  vol. 12,  no. 10 


2*11 


McKeeman,  W.M;  An  Approach  to  Computer  Language  Design; 
Stanford  University,  Department  of  Computer  Science, 
Technical  Report  CS48  (August  1966)  pp.  1-124. 

The  major  responsibility  of  language  design  should 
rest  with  the  user.  In  order  to  reduce  the  compiler- 
writing  task  to  one  a  user  might  undertake,  implement 
an  extendable  compiler  for  a  kernel  language  which 
contains  the  concepts  common  to  all  computing  tasks. 


Brown7Q 


8*10 


Brown,  W.S.;  Software  Portability;  in  Buxton,  J.N.,  and 
Randell,  B.  (ed.).  Software  Engineering  Techniques 
(1970)  pp. 80-84. 

There  can  be  no  dispute  that  software  portability 
is  one  of  the  central  problems  in  software  engineering. 
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Brown*s  solution  to  the  problem  is  to  write  all  his 
software  (ALTRAN  F)  in  FORTRAN  with  a  macro  processor 
(H6)  which  accomodates  various  dialects  of  FORTRAN 
(e.g.  INTEGER  *  2  in  360  FORTRAN).  This  is  perhaps 
sufficient  comment  on  the  state  of  the  art  of  software 
portability . 

FeldmanGB  CR14,729  5*10 

Feldman,  J.,  and  Cries,  D. ;  Translator  Writing  Systems; 
Communications  of  the  ACM,  vol.11,  no. 2  (Feb.  1968) 
pp. 77-113. 
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Richards,  M. ;  BCPL:  A  Tool  for 
Writing;  Proceedings  of  the  SJCC, 
566 . 


Compiler  and  System 
vol.34  (1969)  pp.557- 


13CPL  is  a  simplification  of  CPL  (Basic  CPL) 
developed  as  a  tool  for  writing  relatively  machine 
independent  systems  programs,  especially  compilers. 
The  most  important  characteristic  of  the  language  is 
its  simple  semantic  structure  built  around  "an 
idealized  object  machine”  which  makes  BCPL  reasonably 
machine  independent  and  easy  to  define  accurately.  The 
language  is  type less  (the  only  data  object  being  a  bit 
string  of  implementation-defined  length)  and  has  a 
wealth  of  constructs  to  control  flow  in  an  orderly 
fashion.  The  article  gives  an  interesting  discussion 
of  the  advantages  of  typeless  languages  and  has  some 
general  comments  on  design  of  languages  for  system 
implementation. 
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Brophy,  H.F.  ;  Improving  Programming  Performance; 
Australian  Computer  Journal,  vol.2,  no. 2  (May  1970) 
pp. 66-70. 
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solve  a  variation  of  a  previously  solved  problem. 
Brophy  suggests  the  use  of  decision  logic  tables,  more 
comments,  more  meaningful  variable  names,  better 
documentation  cross  referenced  with  the  program,  and 
the  use  of  programming  teams  as  ways  of  better 
utilizing  the  existing  tools  of  software  development. 
Finally,  standards  in  language,  data  structures, 
documentation,  etc.,  are  proposed  to  improve 
communication  between  different  programming  groups  and 
to  improve  the  portability  of  computer  software. 

Dijkstra68c  8*9 

Dijkstra,  E.W.;  Co-operating  Sequential  Processes;  In 

Genuys,  F.  (ed.),  Academic 

Press  (1968)  pp. 43-112. 

The  use  of  semaphores  in  mutual  exclusion  and 
process  synchronization  is  discussed  and  techniques  for 
implementation  co-operation  among  parallel  processes 
are  examined  in  detail.  A  proof  of  correctness  is 
presented  for  the  message  interpreter  for  the  T.H.S. 
System  and  finally  the  Bankers  Algorithm  is  discussed 
as  a  means  of  preventing  deadlock. 

Wirth71b  7*9 

Wirth,  N.;  The  Programming  Language  Pascal;  Acta 
Inf or matica,  vol.1,  no. 1  (1971)  pp. 35-63. 

Sammet71  4*9 


Sammet,  J.E.;  A  Brief  Survey  of  Languages  Used  in 
Systems  Implementation;  SIGPLAN  Notices,  vol.6,  no. 9 
(October  1971)  pp.1-19. 

A  good,  concise  survey  which  touches  upon  the 
following  topics:  managerial  and  technical  reasons  for 
deciding  to  program  in  a  high-level  language;  some  of 
the  obvious  drawbacks  to  high-level  languages;  a  list 
of  "motherhood”  criteria  for  desirable  programming 
language  characteristics;  brief  and  not- too-usef ul 
descriptions  of:  ALGOL,  BLISS,  FORTRAN,  IMP,  LRLTRAN, 
NELIAC,  Pascal,  an!  PL/I.  Recommended,  and  it*s  short. 
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Balzer;  R.M.;  Dataless  Programming;  Proceedings  of  the 
FJCC,  vol.31  (1967)  pp. 535-544. 

In  order  to  provide  for  a  change  in  operations  on 
data,  a  data  structure  must  be  highly  modifiable  if  it 
is  not  to  result  in  gross  inefficiencies.  Balzer 
suggests  that  the  definition  of  a  data  structure  for  a 
collection  of  objects  should  be  specified  independently 
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of  the  operations  on  that  set.  He  therefore  proposes 
the  Dataless  Programming  System  in  which  operations  on 
arrays,  lists  (singly  or  doubly  linked),  rings, 
structures,  composites  of  any  of  these,  and  even  user- 
defined  collections  are  specified  identically.  The 
system  is  extensible;  the  routines  provided  include 
DELETE,  INSERT,  REPLACE,  ADD,  etc.,  allowing  for  set 
operations  such  as  FOR  EACH...  IN  THE  DOMAIN...  SUCH 
THAT. . . 

Constantine68  CR14,168  2*8 

Constantine,  L.L.;  The  Programming  Profession, 
Programming  Theory,  and  Programming  Education; 
Computers  and  Automation,  vol.17,  no. 2  (February  1968) 
pp. 14-19. 

The  classic  challenge  of  programming  has  been  that 
it  lacks  (1)  an  ordered  body  of  knowledge,  (2)  active 
interaction  between  the  practitioners  in  the  field  and 
that  body  of  knowledge  and  (3)  a  systematic  educational 
approach  for  imparting  that  knowledge  to  new  entrants 
in  the  field.  The  author  maintains  that  the  body  of 
knowledge  of  programming  exists,  but  not  in  an 
integrated  form.  He  proposes  two  theories  distinct 
from  each  other,  the  theory  of  programs  and  the  process 
theory  of  programming. 

Programs  consist  of  a  set  of  ordered  statements. 
There  is  a  structure  to  programs  determined  by  the 


relation  of  the  statements.  Programming  is  a  process 
that  involves  human  creativity.  Nevertheless,  it  is 
governed  by  rules,  perhaps  informal,  that  are  usually 
followed.  Much  more  is  known  about  programs  and 
programming  than  is  being  taught.  The  problem  is  that 
most  the  knowledge  is  gained  in  industry  and  most  of 
the  teaching  is  being  done  in  the  universities.  The 
author  maintains  that  a  lack  of  communication  between 
industry  and  the  universities  results  in  the  computer 
scientist  obtaining  an  incomplete  education.  He 
proposes  a  program  that  is  intended  to  remedy  this 
si tua  tion . 

Bergeron71  4*7 


Bergeron,  R.D.,  Gannon,  J.D.,  and  van  Dam,  A.;  Language 
for  Systems  Development;  SIGPLAN  Notices,  vol.6,  no. 9 
(October  1971)  pp. 50-72. 

Brown72  4*7 

Brown,  G.  deW. ;  The  Forum:  Programming,  the  Quiet 
Revolution;  Datamation,  vol.18,  no. 3  (March  1972) 
pp. 147-150. 
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Anderson,  J.P.;  Program  Structures  for  Parallel 
Processing;  Communications  of  the  ACM,  vol.8,  no. 12 
(December  1965)  pp. 786-788. 

Without  any  references  to  Conway63b,  Anderson 
(superficially)  proposes  the  use  of  FORK,  JOIN, 
TERMINATE,  OBTAIN,  and  RELEASE  for  organizing 
concurrent  program  segments  for  machines  such  as  the 
IBM  360/67  and  the  GE635. 


Balzer 68 


Balzer,  R.M.;  Block  Programming  in  OS/360  Assembly 
Code;  Rand  Corporation,  Santa  Monica,  Cal.,  no.  P-3810 
(May  1968)  pp . 1- 26. 

Brooker67  CR13,438 

Brooker,  R.,  Morris,  D. ,  and  Kohl,  J. ;  Experience  with 
the  Compiler  -  Compiler;  The  Computer  Journal,  vol.9, 
no. 4  (Feb.  1967)  pp. 345-349. 

Cheat ham7 1 


Cheatham,  T.E.;  The  Recent  Evolution  of  Programming 
Languages;  Proceedings  of  IFIP  Congress  1971,  Booklet  I 
(August  1971)  pp. 118-134. 

Conway63a  CRB , 024 

Conway,  M.E.;  Design  of  a  Seperable  Transition  Diagram 
Compiler;  Communications  of  the  ACM,  vol.8  no. 7  (July 
1963)  pp. 396-408. 

Dijkstra63  CH5,696 

Dijkstra,  E.W.;  On  the  Design  of  Machine  Independent 
Programming  Languages;  in  Goodman,  R.  (ed.).  Annual 

R eview_in_ Automat ic _ Programming^  vol.  3,  Pergammon 

Press,  N.Y.  (1963)  pp. 27-42. ~ 

Falkof f  70 

Falkoff,  A.D. ;  Criteria  for  a  System  Design  Language; 
in  Buxton,  J.N.,  and  Randell,  B.  (ed.) ,  Software 
Engineering  Techniques  (1970)  pp. 88-93. 
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Fisher 72 


Fisher,  D.A.;  A  Survey  of  Control  Structures  in 
Programming  Languages;  SIGPLAN  Notices,  vol.  7,  no. 
11  (November  1972)  pp.1-14. 
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(ed.) ,  The_Fourth_Generation  (1971)  pp. 299-312. 

Henricksen72  CR23,805 

Henriksen,  J.O.,  and  Merwin,  R. E.  ;  Programming  Language 
Efficiency  in  Real-Time  Software  Systems;  Proceedings 
of  the  SJCC,  vol. 40  (1972)  pp. 155-161. 
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Lock,  K. ;  Structuring  Programs  for  Multi-Program  Time¬ 
sharing  On-Line  Applications;  Proceedings  of  the  FJCC, 
vol.27,  part  1  (1965)  pp. 457-472. 

The  paper  introduces  the  idea  of  incremental 
compilation,  a  scheme  of  structuring  users*  ALGOL 
programs  in  accordance  with  the  syntactical  unit  of  a 
"statement"  which  enables  the  user  to  make 
modifications  to  his  source  language  program  at  the 
statement  level  without  recompiling  the  complete 
program. 
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Manacher,  G.K.;  Some  Design  Principles  for  High  Level 
Systems  Programming  Languages;  University  of  Chicago, 
Institute  for  Computer  Research,  ICR  Quarterly  Report 
No. 25  (May  1,  1971)  pp.1-17. 

The  attributes  of  high-level  lan 
PL/I,  CPL )  and  those  of  low-level  langua 
PL360)  are  listed.  A  combination  of  thes 
taken  as  the  design  strategy  for  ESPL  a 
high-level  convenience  (phrase  structure 
structure,  extensibility,  protection,  an 
low-level  features  (machine-depen 

specification,  register  access,  system 
emitted) .  The  criteria  are  vague  and  the 
how  much  of  any  feature  is  desirable  is  n 

McFarland70  CR21,223 

McFarland,  C.  ;  A  Language-oriented  Computer  Design; 
Proceedings  of  the  FJCC,  vol.37  (1970)  pp. 629-640. 

Difficulties  in  using  computers  are  often  the 
result  of  poor  system  design  or  a  mismatch  between  the 
language  and  the  computer  being  used.  It  is  the 
responsibility  of  the  user  to  produce  a  good  algorithm 
for  solving  his  problems,  but  he  is  entitled  to  assume 
that  good  construction  in  a  higher  level  language  will 
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author  seeks  to  identify  the  reasons  why,  in 
what  Mother  has  told  us,  we  continue  to  pay  no 
lip  -service  to  the  principles  of  good  system 
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compilers,  with  the  following  principal  advantages: 

1*  The  abstract  machine  may  be  flexibly  extended. 
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The  article  discusses  the  possibility  of  extending 
a  subset  of  the  PL/I  language  for  use  in  compiler  and 
operating  system  writing.  The  primary  aims  of  high 
level  languages  are  machine  independence  and 
readability.  This  is  contrasted  with  the  need  of  the 
producers  of  software  to  have  full  control  over  all  the 
features  of  the  machine.  Therefore  the  solution  of  the 
problem  is  not  a  general  high  level  language,  but  one 
that  is  tailored  to  the  given  computer,  while  at  the 
same  time  retaining  some  of  the  good  features  of  a  high 
level  language.  The  author  suggests  a  subset  of  PL/I 
with  some  extensions  which  he  describes  in  the  article, 
which  would  become  a  good  language  for  software 
writing. 
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V.  Correctness ,  validation f  and  debugging 
Floyd7 1 

Floyd,  R.W.;  Toward  Interactive  Design 
Programs;  Proceedings  of  IFIP  Congress 
pp. 1 -4 . 
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of  Correct 
1971  (1971) 


An  imagined  interaction  between  a  computer 
programmer  and  his  machine  is  described,  in  which  the 
computer  checks  the  program  for  consistency  with  the 
programmer’s  stated  intentions,  and  proves  the  logical 
or  semantic  correctness  of  the  program  at  various 
levels. 
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Dijkstra,  E.W.;  Concern  For  Correctness  as  a  Guiding 

Principle  for  Program  Composition;  The _ Fourth 

ion^  Infotech,  Ltd.,  Berkshire,  England  (1971) 
pp. 357-367. 

In  this  state  of  the  art  report,  Dijkstra  reviews 
the  current  state  in  the  programming  world,  and  notes 
the  unfortunate  situation  with  respect  to  programming 
and  debugging  practices.  As  an  alternative  to  this,  he 
proposes  and  presents  a  strong  argument  for  a 
structural  approach  to  the  construction  of 
,f  intellectually  manageable”  programs  which  yields 
correctness  proofs  with  much  less  effort. 
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Dijkstra,  E.W.;  A  Constructive  Approach  to  the  Problem 

Correctness;  BIT,  vol.8,  no.  3  (1968) 


of 

PP 


Program 

174-186. 


Dijkstra  states  that  there  are  two  ways  to 
establish  the  correctness  of  a  program.  As  an 
alternative  to  a  posteriori  techniques  this  paper 
proposes  that  a  priori  correct  programs  can  be  produced 
by  controlling  the  process  of  program  generation 
manner  that  is  demonstrated  on  a  simple  problem. 


in 
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London,  R.L.;  Proving  Programs  are  Correct: 
Techniques  and  Examples;  BIT,  vol.  10,  no.  2 

pp . 1 68- 182. 

The  advantages  and  feasibility  of 
correct  are  demonstrated.  Among 
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technique  provides  the  programmer 
systematically  searching  for  errors  and  that  the 
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Burstall,  R.M.;  Proving  Properties  of  Programs  by 
Structural  Induction;  The  Computer  Journal,  vol.  12, 
no. 1  (February  1969)  pp. 41-48. 

This  paper  presents  the  technique  of  structural 
induction  for  proving  the  validity  of  the  type  of 
programs  where  repetition  is  accomplished  by  recursion, 
and  jumps  and  assignment  are  avoided.  The  author 
considers  the  technique  of  structural  induction  a  very 
powerful  tool  which  is  easy  to  use  and  gives  a  clear 
explanation  in  ordinary  mathematical  terms  of  why  a 
program  works  as  it  does.  The  technique  depends  on  the 
structure  of  the  data  manipulated  by  the  program,  and 
the  objective  is  to  prove  not  just  that  the  program 
works  for  specimen  input  data  but  that  it  will  work  in 
general  for  an£  input  data. 


The  author  feels  that  the  first  step  should  be  to 
devise  methods  of  proof  of  validity  of  non-trivial 
programs  in  a  comprehensible  manner.  The  reasoning 
might  later  be  formalized  to  a  point  where  it  can  be 
performed  by  a  computer  to  provide  mechanized  debugging 
a  ids. 

The  main_aim  of  the  paper  is  to  suggest  some 
syntactic  devices  for  writing  programs  in  a  way  which 
facilitates  the  derivation  of  proofs  by  structural 
induction.  The  form  of  these  proofs  would  then  be 
similar  to  that  of  the  corresponding  programs.  The 
author  believes  that  the  discipline  of  stating  theorems 
and  devising  proofs  will  greatly  improve  programming 
education  and  practice. 
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progress  has  been  made  although  this  effort  has  lead  to 
advances  in  programming  languages,  theory  of 
algorithms,  and  system  theory. 
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and  by  a  program  written  for  that 
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King,  J. ;  A  Verifying  Compiler;  in  Rustin,  R.(ed.), 

Debugging _ Techniques _ iH_!!£!£_Systems^  Prentice-Hall , 

Inc.  (1971)  pp. 17-40. 

In  this  article,  a  special  compiler  is  described, 
one  that  not  only  compiles  a  program,  but  allows  you  to 
prove  that  the  program  will  always  execute  correctly. 
For  illustration  purposes,  a  sample  program  to  be 
compiled  is  annotated.  Propositions  about  relations 
among  its  variables  are  made.  If  consistency  is  found 
between  these  propositions,  as  the  flow  of  the  program 
is  traced,  then  the  program  is  verified  to  be  correct. 
If  inconsistency  is  found,  information  concerning 
errors  is  discovered,  and  can  be  acted  upon. 
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Blair,  J. ;  Extendable  non-Interactive  Debugging;  in 
Rustin,  R.  (ed.)  ,  Debugging_Technigues_in_Large_Sys te ms^ 
Prentice- Hall  (1971)  pp. 93-115. 
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(1971)  pp . 57-75. 
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The  features  of  a  good  debugging  system  language 
are  disc  ussed  and  compared  with  current  debugging 
facilities  (both  for  batch  and  interactive  systems) . 
The  various  implementations  of  an  interactive  debugging 
system  are  compared  according  to  efficiency, 
determination  of  compiler  and  assembly  language  errors. 
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language-specif ic  checks,  and  ease  of  modifications. 
An  overview  of  the  author*s  own  debagging  system,  AIDS, 
is  presented,  and  an  example  of  a  sample  debugging  run 
using  AIDS  is  given.  The  success  of  AIDS  is 
guest ion ed,  because  of  the  difficulties  encountered  in 
loading  the  language  for  time  sharing  use  and  learning 
to  use  this  complicated  system. 
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of  achieving  high  relia 
computing  systems.  System  perfor 
reliability  are  both  commodities  for 
to  pay.  Usually,  they  are  inversely  related  (e.g., 
high  system  reliability  usually  means  a  loss  in  system 
performance) .  Operating  systems  are  intended  to  extend 
the  reliability  of  and  to  cope  with  the  unreliability 
of  the  hardware.  However,  it  may  turn  out  that  the 
operating  system  presents  a  bigger  reliability  problem 
than  the  hardware.  In  a  computing  system,  it  should  be 
the  responsibility  of  the  hardware  to  detect  hardware 
errors  and  the  responsibility  of  the  operating  system 
to  cope  with  and  isolate  these  errors. 
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In  conclusion  Randell  states  that  "the  most  vital 
task  to  be  undertaken  in  designing  a  computing  system 
for  a  highly  critical  and  complex  environment  is  that 
of  attempting  to  minimize  the  extent  to  which  reliance 
is  put  on  the  correct  and  continuing  functioning  of  the 
system”. 
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In  this  article,  a  classification  of  bugs  is 
outlined  including  type,  frequency,  and  habitat.  The 
"process  of  bug  extermination"  is  reviewed,  and 
suggestions  for  improvement  of  debugging  tools  is 
discussed.  Structure  of  programs  and  proofs  of  program 
correctness  are  examined.  The  dimensions  of  time  and 
space  in  the  debugging  process,  as  well  as  an  ideal 
debugging  language  are  considered. 
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Hanford  describes  his  "syntax  machine".  This  is  a 
program,  which  he  has  implemented  on  S/360,  which 
produces  programs  which  are  syntactically  correct  (but 
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Correction  for  Compiling;  Ph.  D.  Thesis,  Iowa  State 
University,  Department  of  Computer  Science  (1970)  pp.1- 
205. 

This  thesis  presents  a  basic  theory  for  the 
development  of  an  error  corrector.  The  use  of  this 
theory  should  provide  one  additional  debugging  tool  for 
the  high-level  language  programmer.  Techniques  are 


53 


developed  for  automatically  determining  the  existence 
of  errors,  locating  errors,  and  choosing  the  most 
probable  correction. 

An  error  corrector  was  developed  for  a  selected 
subset  of  high-level  language  programs  which  use  the 
WATFOR  compiler.  The  corrector  was  implemented  using 
the  following  steps: 

1.  A  random  sample  of  programs  which  use  the  WATFOR 
compiler  was  obtained. 

2.  Statistics  were  gathered  so  that  programs  could  be 
described  in  terms  of  the  errors  that  programmers 
make. 

3.  Correction  algorithms  were  developed  for  the  most 
common  errors. 

4.  The  algorithms  were  coded  as  correction  programs. 

5.  The  correction  program  was  applied  to  the  WATFOR  job 
stream . 
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pp. 1-  162- 

This  thesis  presents  a  system  of  automatic  error 
recovery  for  syntax  directed  parsing  algorithms  which 
is  based  solely  on  the  syntax  of  the  language.  This 
method  is  not  only  automatic,  requiring  no  additional 
effort  from  the  language  designer  beyond  the  syntactic 
specification  of  his  language,  but  it  also  is  much  more 
effective  than  most  hand  written  systems.  In  a  set  of 
programs  run  on  four  different  compilers  constructed 
using  this  system,  only  six  out  of  140  errors  were 
missed  and  92  out  of  the  134  errors  detected  were 
described  to  the  programmer  exactly.  In  only  nine  of 
the  134  detected  errors  was  the  message  about  the  error 
apt  to  be  confusing. 
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Dijkstra70b,  Dijkstra71a,  Dijkstra71c,  London70c , 
McCarthy67,  Naur66,  Naur69a,  Smith72,  Snowdon70, 
Snowdon72,  Wood69; 

Testing : 

GarwickSI,  Ginzberg55,  Gould71,  Hanford70,  Landy71, 
Needham70a,  Parnas72b,  Poole72,  Vander  Noot71; 

Automatic  generation  of  test  cases: 

Gould71,  Hanford70; 


Debugging : 


Balzer69,  Bernstein68,  Blair71,  Brady68 
EvansGS,  Evans66,  FergusonSB,  Gaines69 
Grishman71,  Henderson72,  Jonsson68, 
Katzenelson7 1 ,  Kulsrud69,  Kulsrua71, 
Lester71,  Poole72,  Rustin71,  Schwartz71 


Burstall69 , 
Grishman70 , 
Josephs6  9 , 
Lasset tre7  2 , 
S  toe kham66 , 


Supnik71,  Teitleman70,  Van  Horn68,  Ver  Steeg64; 


Syntax  error  recovery: 

Gries71,  Hedrick70,  LaFrance71; 
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71.  Evaluation 


Graham7 1 


3*15 


Graham,  R.M.,  Clancy,  G.J.,  and  DeVaney,  D.B.;  A 
Software  Design  and  Evaluation  System;  Proceedings  of 
the  ACM/SIGOPS  Workshop  on  System  Performance 
Evaluation  (April  1971)  pp. 200-213. 

There  are  two  primary  drawbacks  to  modelling  as  a 
part  of  the  implementation  process.  First  is  the  need 
to  construct  the  model  separately  from  the  system, 
diverting  people  from  the  primary  objective.  Second  is 
the  problem  of  keeping  the  model  current  as  the  system 
primitives  are  re-defined. 

DES  makes  use  of  a  single  language  to  describe  the 
object  system  at  all  levels  of  design  and 
implementation.  In  this  way  simulation  goes  hand-in- 
hand  with  design  and  the  performance  of  the  final 
system  may  be  accurately  estimated  before  full 
implementation,  potentially  saving  a  costly  re-design. 


ZurcherbB 
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Zurcher  and  Randall  propose  basically  a  system  model 
which  produces  a  working  implementation  as  a  (very) 
useful  side-effect.  Recommended. 


Par nas67 


CR1 4 ,055 


3*10 


Parnas,  D.L.,  and  Darringer,  J.A.;  SODAS  and  a 
Methodology  for  System  Design;  Proceedings  of  the  FJCC, 
vol.  3  1  (1967)  pp.  449-474  . 


SODAS  is  the  first 
attempt  to  combine 
implementation  in  an 
production  efficiency, 
"object  system”  to  be  s 
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imposed  by  high-level  design  decisions  vill 
significantly  impact  the  performance  of  the  resulting 
system.  Parnas’s  system  has  several  drawbacks 
(compared  to,  say,  R.M.  Graham’s  D.E.S.);  primarily 
the  use  of  several  different  languages  is  confusing, 
particularly  since  the  implementation  language  is 
distinct  from  the  simulation  language  (s) . 

Gotlieb70  7*9 

Gotlieb,  C.C.,  and  MacEwan,  G. H. ;  System  Evaluation 
Tools;  in  Buxton,  J.N.,  and  Randell,  B.  (ed„). 
Software  Engineering  Techniques  (1970)  pp. 93-99. 

Arbuckle66  CR9,553  3*7 

Arbuckle,  R.A.;  Computer  Analysis  and  Thruput 
Evaluation;  Computers  and  Automation,  vol. 15,  no.  1 
(January  1966)  pp. 12-15,  19. 


Arbuckle  maintains  that  computer  efficiency  should 
be  measured  in  terms  of  thruput  (number  of  jobs 
completed  per  unit  time)  rather  than  raw  internal 
power.  He  elaborates  other  methods  of  evaluation 
(including  core  cycle  time,  add-time,  instruction  time, 
instruction  mix,  kernel  problems,  benchmark  problems) 
and  points  out  their  shortcomings.  Unfortunately, 
working  tor  a  hardware  manufacturer,  Arbuckle  only 
considers  hardware  modifications  to  improve  efficiency. 


Arden69 


Arden,  B.W.,  and  Boattner,  D.;  Measurement  and 
Performance  of  a  Multiprogramming  System;  Proceedings 
ACM  Second  Symposium  on  Operating  Systems  Principles 
(Oct.  1969)  pp. 130-146. 

This  paper  opens  with  a  brief  description  of  the 
University  of  Michigan  Multi-Programming  System  (UMMPS) 
and  MTS  in  order  to  lay  the  foundation  for  a  discussion 
of  software  measurement.  It  then  describes  two  basic 
types  of  measurement  (  (1)  processor  time  and  elapsed 
time  (2)  "microscopic”  recording  of  certain  events  over 
a  short  period  of  time)  and  how  they  may  be  applied  to 
large  systems  (in  particular  UMMPS) .  Finally  a  measure 
of  time  sharing  efficiency  (ideal  response  time  over 
actual  response  time)  is  introduced  and  several  tables 
and  graphs  are  presented  to  display  various  performance 
characteristics. 


Bar d7  1 

Bard,  Y. ;  CP-67  Measurement  and  Analysis;  Proceedings 
of  ACM/SIGOPS  Workshop  on  System  Performance  Evaluation 
(April  1971)  . 
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Discusses  the  statistical  and  measurement 
techniques  used  to  compare  various  releases  of  CP-67 
with  respect  to  throughput,  overhead,  etc.  This  paper 
is  interesting  for  several  reasons.  CP-67  is  an  easy 
system  on  which  to  perform  relatively  interference-free 
measurements.  Additionally,  the  application  of  the 
results  of  this  and  a  prior  study  led  to  a  re-design  of 
some  modules  with  dramatic  improvement  in  performance. 

Bard7  2 

Bard,  Y. ,  and  Suryanarayana,  K.V.;  On  the  Structure  of 
CP-67  Overhead;  in  Freiberger,  W.  (ed.),  Statistical 
Computer_Perf ormance_Evaluat ion^  Academic  Press  (1972). 

Regression  analysis  lives  again  in  this  thrilling 
tale  from  the  annals  of  I B FI  •  s  history.  Still,  it*s  a 
good  way  to  determine  actual  software  bottlenecks,  and 
those  concerned  with  producing  efficient  real-time 
programs  should  probably  be  acquainted  with  the  uses  of 
the  technique. 

Campbell68  CRl6,874 

Campbell,  D.J.,  and  Heffner,  W.J.;  Measurement  and 
Analysis  of  Large  Operating  Systems  During  System 
Development;  Proceedings  of  the  FJCC,  vol.33,  part  1 
(1968)  pp. 903-914. 

While  this  paper  touches  upon  simulation  and  other 
methods  to  pre-e valuate  system  performance,  the  primary 
thrust  is  on  the  incorporation  of  on-line  measurement 
tools  into  the  evolving  system  so  that  performance  may 
be  monitored  and  improved  once  operation  begins.  The 
strategic  placement  of  measurement  hooks  requires  that 
the  critical  parameters  of  the  final  system  be 
identified  in  advance,  a  task  which  can  lead  to  better 
implementation  in  the  first  place. 

Cantrell68 

Cantrell,  H.N.,  and  Ellison,  A.L.;  Multiprogramming 
System  Performance  Measurement  and  Analysis; 
Proceedings  of  the  SJCC,  vol.  32  (1968)  pp. 213-222. 

Deniston69  CRIB, 278 

Deniston,  W.R.;  SPIE:  A  TSS/360  Software  Measurement 
Technique;  Proceedings  of  the  ACM  24th  National 
Conference  (1969)  pp. 229-245. 
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Deu tsch7 1 


Deutsch,  P.,  and  Grant,  C.A.;  A  Flexible  Measurement 
Pool  for  Software  Systems;  Proceedings  of  IFIP  Congress 
1971,  Booklet  TA-3  (1971)  pp.7-12. 

Fox67  Cfi 1 4 , 067 

Fox,  D.,  and  Kessler,  J.L.;  Experiments  in  Software 
Modeling;  Proceedings  of  the  FJCC,  vol.  31  (1967) 
pp. 4  29-4  36. 

Hatf ield7 1  CK23,271 

Hatfield,  D.,  and  Gerald,  J.  ;  Program  Restructuring  for 
Virtual  Memory;  IBM  Systems  Journal,  vol.  10,  no.  3 
(1971)  pp. 168-192. 

Much  effort  has  been  directed  of  late  to  the 
improvement  of  problem-program  performance  on  virtual 
memory  systems.  This  paper  describes  a  procedure  for 
determining  the  memory-use  characteristics  of  a  program 
and  then,  through  a  combination  of  automatic  and  manual 
algorithms  and  heuristics,  rearranging  the  to  improve 
paging  behavior,.  The  method  described,  as  opposed  to 
many,  is  practical,  in-use,  and  results  in  a 
(typically)  5  to  1  improvement. 


Kimbleton72 
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Lassettre72 


Lassettre, 
Perf  orma  nee 
Fr eiberger , 
Evaluation^ 


E.R.,  and  Scherr,  A.L.;  Modelling  the 
of  the  OS/360  Time-Sharing  Option  (TSO) ;  in 
W.  (ed.) ,  Statist ical_Computer_Perf or mance 
Academic  Press  (1972). 


When  properly  handled,  modelling  can  be  an 
invaluable  tool  in  the  design  of  a  per  for mance- bound 
software  system.  This  paper  describes  an  extremely 
successful  application  of  modelling  to  the  design. 


62 


debugging  and  modification  of  a 
operating  system. 

Measurements  taken  during  the 
TSO  were  continually  compared  to  the 
model,  a  reasonably  simple  analytica 
and  driven  by  observations  of  ot 
’’accuracy”  of  the  model  was  such 
discrepancies  were  usually  traced 
itself.  The  model  thus  served  at  lea 
early  prediction  of  ultimate 
identification  of  performance 
implementation. 

Lucas71  CR23,420 

Lucas,  H.C.;  Performance  Evaluation 
Computing  Surveys,  vol.3,  no. 3  (Sept 

91. 

Margolin72 

Margolin,  B.H.,  Parmelee,  R.P.,  an 
Analysis  of  Free  Storage  Algorithms; 

(ed.) ,  Statistical _ Computer _ Pert or 

Academic  Press  (1972). 

A  description  of  an  excellent  m 
measurement,  statistical  technique 
experiment  design  which  resulted 
improvement  in  the  CP-67  operatin 
recommended  to  those  interested  in 
software  into  shape. 

Miller72 

Miller,  E.F. ;  Bibliograpy  on  Techni 
Perfomance  Analysis;  Computer,  vol.5 
October  1972)  pp. 39-47. 
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improve  their  operating  efficiency. 
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Seaman69  CR18,985 

Seaman,  P.H.,  and  Soucy,  R.C.;  Simulating  Operating 
Systems;  IBM  Systems  Journal,  vol.8,  no. 4  (1969) 
pp. 264-279. 

ieider man7 1 

Weiderman,  N.H.;  Synchronization  and  Simulation  in 
Operating  System  Construction;  Ph.D.  Thesis,  Cornell 
University,  Department  of  Computer  Science  (September 

1971)  . 

Description  of  an  operating  system  design 
methodology  which  proceeds  in  a  strict  top-down  order 
and  combines  simulation  with  implementation  to  verify 
system  structure  and  predict  object-system  performance. 
A  good  review  of  other  techniques  is  included;  chapters 
three  and  four  are  of  particular  interest.  For 
comparison  purposes,  see  Graham’s  D.E.S.,  Parnas's 
SODAS  and  the  Zurcher  and  Randell  paper. 


TOPICS 

Evaluation; 

Ar buckle66,  Cantrell68,  Cheatham72,  Gotlieb70,  Kay69, 
Kimbleton72,  Miller72,  Randell71b; 

Modelling: 

Bard72,  Fox67,  Lassettre72,  Margolin72; 

Simulation : 

Campbell68,  Graham71,  Parnas67,  Parnas69b,  Seaman69, 
Supnik71,  Weiderman71,  ZurcheroB; 

Monitoring : 

A  r  d  e  n  6  9 ,  Bard71,  Campbell68,  Deniston69,  Deutsch71, 
Hatfield71,  Lucas71,  Pinkerton69; 
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VII.  Documentation 


Conro v7  0 


5*10 


Conrow,  K.  ,  and  Smith,  R.G.  ;  NEATER2:  A  PL/I  Source 
Statement  Reformatter;  Communications  of  the  ACM, 
vol. 13,  no.  11  (1970)  pp. 669-675. 


The  paper  descri 
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Goos7  2 


Goos,  G. ;  Documentation;  Advanced  Course  on  Software 
Engineering,  Technical  University  of  Munich  (1972). 


Meadow66 

CR  13,305 

Meadow,  C.T. , 

and  Waugh, 

D . V. ;  Computer 

Assisted 

Interrogation ; 
pp. 381-394. 

Proceedings  of 

the  FJCC,  vol. 

29  (1966) 

Mills7  0 

CR19, 422 

Mills,  H.D.;  Syntax-directed 

Documentation  f 

or  PL360 ; 

Communications 

of  the  ACM, 

vol.  13,  no. 

4  (April 

1970)  pp. 216-222. 

Sco wen7  1 

Scowen,  R.S.,  Allin,  D. ,  Hillman,  A.D.,  and  Shimell, 
M . ;  SOAP  -  A  Program  Which  Documents  and  Edits  ALGOL  60 
Programs;  Computer  Journal,  vol.  14,  no.  2  (1971) 

pp.  133-135. 

Selig69 

Selig,  F.  ;  Documentation  Standards;  in  Naur,  P.  ,  and 
Randell,  B.  (ed.).  Software  Engineering  (1969)  pp.209- 

211. 


Walsh 6 9  CR 1 9 , 39  2 

Walsh,  D. ;  A_Gu ide_t o_S of t ware _ Docu men ta tionq  McGraw- 

Hill,  N.Y.  (1969)  pp. 1-157." 
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Other  documentation  papers: 

Bemer69,  Brophy70,  Fosdick72,  Garwick61, 
Parnas7 1b ; 


Kay69, 


66 


VIII; _ Miscellaneous 

Needham70b  6*16 


Needham,  R.M.,  and  Aron 
Computer  Science;  i 
B.(ed.),  Software  Engin 
pp. 113-114. 

Computer  science 
principles  underlying 
software  systems.  The 
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software  engineering 
development  of,  and  t 
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aims  at  defining  general 
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inuity  during  development,  etc." 


Boering68 

Boering,  B.W.;  The  "System  Generator":  The  Ultimate  in 
Software;  Computers  and  Automation,  vol.17,  no. 3  (March 
1968)  pp. 36-37. 


Bright 66 


CHI  4, 974 


Bright,  H .  ; 
Executive 
A  utomation. 


Towards 
Systems 
vol . 15, 


Greater  Generality  of  Software: 
in  the  Sixties;  Computers  and 
no. 2  (Feb.  1966)  pp. 44-64. 


Cheathara72 


CR2  3,934 


Cheatham,  T.E.,  and  Wegbreit,  B.  ;  A 
Study  of  Automating  Programming; 
SJCC,  vol.  40  (1972)  pp.  11-21. 
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Donovan70 

Donovan,  J.J.;  Software  Engineering  -  An  Experiment  and 
a  Report;  IFIP  World  Conference  on  Computer 
Education (1970) . 

Maurer70  CR21,548 

Maurer,  W.;  Generalized  Interpretation  and  Compilation; 
in  lou,  J.T.  (ed.),  Soft  war  e_EngineeringJL  vol.  1, 
Academic  Press,  N.Y.  (  1970)  pp.  139-  1  50. 

Parnas72a 

Parnas,  D.L.;  A  Course  on  Software  Engineering 
Techniques;  SIGCSE  Bulletin,  vol.  4,  no.  1  (March 
1972)  pp. 154-159. 


Perlis69 


Perlis,  A.J.;  Identifying  and  Developing  Cirricula  in 
Software  Engineering;  Proceedings  of  the  3JCC,  vol.  34 
(1969)  pp. 540-541. 

Teitleman70 

Teitleraan,  K.  ;  Toward  a  Programming  Laboratory;  in 
Buxton,  J.N.,  and  Randell,  B.  (ed.).  Software 
Engineering  Techniques  (1970)  pp.  137-  149. 


TOPICS 
Educa  tion: 

Buxton71,  Constant ineoB ,  Corbin71,  Donovan70, 

Needham70b,  Parnas72a,  Perlis69; 

Labora  tories: 

Cheathara72,  Corbin71,  Teitleman70; 

Systems  for  writing  systems: 

BoeringbB,  (see  also  translator  writing  systems)  ; 
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